没有新通知
更多
涨跌颜色
涨跌幅起始时间
- 话题
98k 帖子
63k 帖子
57k 帖子
56k 帖子
53k 帖子
46k 帖子
44k 帖子
43k 帖子
39k 帖子
39k 帖子
- 置顶
- AIMeme 板块仍有热度，艺术品和网红动物 Meme 暂时熄火，政治 Meme 热度再起
- 📢 Gate.io动态 #打榜优质内容# 重磅来袭！发布优质内容，赢取专属奖励！
🌟 每周精选优质发帖内容，张榜发布，增加曝光，助力荣誉提升！
💡 如何参与？
1.带上 #打榜优质内容# 标签并发布优质内容贴，即视为成功参与。
2.帖子需要满足60字以上且获得3个及以上点赞。
3.打榜的帖文不得包含除 #打榜优质内容# 之外的其他标签，否则将无法获得奖励。
🎁 将在每周一、三、五各选出1篇优质内容贴，赢取每周$20上榜奖励！
📃 张榜发布优质内容于动态！
📌 奖励将于14个工作日内完成发放，请提前完成高级认证！
🏆想要你的帖子脱颖而出？成为优质内容分享员，分享市场洞察，让更多人看到你
- #交易机器人 # 跨所套利#
🤖 Gate.io 独家跨所套利机器人上线！
🛡️开启无风险交易，普通用户也可享顶级机构盈利模式！
💰收益翻倍，瓜分100,000 USDT！
🏆加入收益擂台赛！冠军享500 USDT收益奖！
🔗 参与报名：https://www.gate.io/announcements/article/40402
- 🇺🇸 大选前夕资金避险意识强烈，BTC ETF流出超$5亿；FEARNOT等特朗普概念meme上涨...
- 🎉 荣誉积分第4️⃣期抽奖狂欢活动正在进行中！
前面1、2、3期都错过了，还想接着错过吗？
Macbook、精美周边等大奖还没抽完，快来接住你的好运！
立即抽奖 👉 https://www.gate.io/activities/creditprize?now_period=4
了解更多：https://www.gate.io/announcements/article/40218
#荣誉积分#
以太坊 L2 中的欺诈证明状态
1. 前言
1.1. Optimistic Rollup 的未来方向
2024 年 9 月，Vitalik 强调了提升 Rollup 标准的必要性，并表示：
我对此非常重视。从明年开始，我只会在博客、演讲等场合公开提及那些已经达到阶段1以上的 L2，也许对一些新的、有趣的项目会有一个短暂的宽限期。
无论我是否投资，或你是不是我的朋友，都必须达到第一阶段，否则不提。
Rollup 的“阶段”系统是一个用于粗略评估其安全性水平的框架，从阶段0到阶段2。如今的主流 Rollup 中，只有 Arbitrum 和 Optimism 达到了阶段1，其他大多数 Optimistic Rollup 目前仍处于阶段0。
在这种情况下，出现了一些问题：
本文旨在通过分析 Optimistic Rollup 的欺诈证明和挑战机制来回答这些问题，并探讨每个项目如何努力实现阶段2。此外，本文还将展望 Optimistic Rollup 和欺诈证明系统的未来发展。
1.2. Optimistic Rollup 与 ZK Rollup 的对比
众所周知，以太坊速度慢且交易费用高。以太坊社区的研究人员和开发者们一直在努力解决这一问题。在探索了分片（sharding）和 plasma 等解决方案后，社区最终确定 Rollup 是实现扩展性的主要途径。因此，像 Arbitrum、Optimism 和 zkSync 这样的 Rollup 纷纷涌现。根据 L2Beat 的数据，目前大约有 40 个 Rollup 正在运行，另外一些解决方案如 Validium 和 Optimium 采用了 alt-DA 方案来实现更高的扩展性，总数约为 41 个。此外，预计将有大约 80 条新的 Rollup 链上线。
（当前 L2 现状 | 来源：L2Beat）
Rollup 的核心概念是在链下执行交易，只向以太坊提交交易数据和结果状态根，从而实现扩展性。用户可以将资金存入以太坊上的特定桥接合约，将资金转移到 Rollup 内部，并在 Rollup 内进行交易。由于交易数据会提交到以太坊，并且一旦确认就无法在不破坏以太坊安全性的情况下更改，因此人们认为 Rollup "继承了以太坊的安全性"。
但这是真的吗？如果 Rollup 内处理交易的提议者是恶意的呢？恶意提议者可能会篡改 Alice 的余额，将其转移到自己的账户中，并将其提取到以太坊，从而有效地盗取 Alice 的资金。
为了防止这种情况，在从 Rollup 提现到以太坊时需要额外的安全机制。通过向以太坊桥接合约提供证明，证明提现交易已正确处理并包含在 L2 链中，提现交易才能完成。
最简单的方法之意，也是每个 Rollup 都采用的方式，是将提现交易的哈希值与 Rollup 的状态根进行比较，以证明该提现交易已正确包含在 Rollup 的状态中。这要求将提现交易和状态根一起提交给以太坊的桥接合约。用户提交他们的提现交易，而验证者计算并提交状态根。
但是，如果提交状态根的验证者是恶意的，并提交了错误的状态根，可能会危及用户资金的安全。为降低这种风险，提出了两种主要机制，致使 Optimistic Rollup 和 ZK Rollup 不同。
为了确保能安全解决诸如 L1 审查等攻击的之意，Optimistic Rollup 的提现时间通常会延迟约一周。
1.3. 为什么需要欺诈证明？
与 ZK Rollup 不同，Optimistic Rollup 的验证者可以提交错误的状态根并试图操控提现交易。欺诈证明有效地防止了这一点，确保了桥接合约中的资金安全。
如果没有强有力的欺诈证明机制，Optimistic Rollup 就不能完全继承以太坊的安全性。例如，在当前 Arbitrum 的许可验证者系统中，如果所有验证者合谋，他们可能会盗取桥接合约中的所有资金。同样，在 Base 等基于 OP Stack 的 Rollup 上，由于主网上还未实现无许可的故障证明机制，单个恶意验证者也可能盗取资金。
因此，欺诈证明在 Optimistic Rollup 的安全性中起着关键作用，任何缺乏完善欺诈证明机制的系统都对用户资产构成风险。
本文将评估各种 Optimistic Rollup 所面临的风险，并检视它们的欺诈证明机制的实施以及优缺点。
1.4. 迈向阶段2：“移除辅助轮”
欺诈证明系统在帮助 Optimistic Rollup 实现“阶段2”过程中发挥了关键作用。Vitalik 提出的阶段框架，目前由 L2Beat 运营，用于评估 Rollup 的安全水平。
在以太坊生态系统中，这个阶段框架通常被比作学习骑自行车。阶段0 的 Rollup 依赖最多的信任假设，被比作带有辅助轮的三轮车，而完全继承以太坊安全性的阶段2 Rollup 则被比作移除辅助轮的两轮车。
以下是阶段0到阶段2各个阶段的详细标准：
正如上文所提到的，要使 Optimistic Rollup 达到阶段1或阶段2，实施一个合适的欺诈证明和挑战机制至关重要。考虑到这些标准，满足阶段2要求的欺诈证明系统应具备以下特征：
在本文的后半部分，我们将探讨各种协议如何尝试实现这些功能。
2. 欺诈证明 - 概念与误解
2.1. 欺诈证明是如何实施的？
欺诈证明提供了链上可验证的证据，表明提交的状态根不正确，意味着 L2 中的某个特定状态转换函数执行不当。一个简单的方法是从上一个确认的状态根开始，为执行所有 L2 区块生成证明，直到当前状态根，从而证明状态根不正确。然而，这种方法代价高昂且耗时。
因此，生成有效的欺诈证明时，需要先缩小到特定的不正确状态转换，再为该部分生成证明。大多数欺诈证明协议都遵循这种方法。
欺诈证明和质疑协议通常包括以下步骤：
2.2. 常见误解：欺诈证明与质疑不会回滚链
需要注意的是，即使发生欺诈证明和质疑，链也不会被回滚。欺诈证明确保的是“桥接合约中的资金不会被恶意提取”，而不涉及不正确状态转换的回滚。
不回滚的主要原因是没有必要。当 Rollup 中发生不正确的状态转换时，核心问题在于恶意行为者可能会从桥接中窃取用户资金。为防止这一点，只需确保提交给 L1 的状态根是正确的。这个过程与链回滚无关，只要防止恶意状态根的最终确认，欺诈证明和质疑机制就已足够。
此外，如果提交状态根的提议者和生成 L2 链块的排序者是不同的实体，那么也没有必要进行回滚机制。
因此，即使成功解决了质疑，L2 链也不会被回滚；只有提交给 L1 的状态根（输出或声明）会被删除或替换。如果欺诈证明和质疑机制正常运行，用户桥接资金的安全就能得到保证。
2.3. 真实案例：2024 年 4 月 Kroma 的质疑
通过实际的质疑案例，可以看到整个 Rollup 链不会被回滚，只有输出根会被替换或删除。截至目前，主网上唯一已知的成功质疑案例发生在 2024 年 4 月的 Kroma，这是一个基于 OP Stack 的混合 Rollup，使用 ZK 故障证明。
Kroma 是一个 OP Stack based Rollup，拥有自己的 ZK 故障证明和无许可验证者系统。2024 年 4 月 1 日，Kroma 排序器的 L1 来源出现问题，导致排序器生成了不正确的区块。此外，观察到这一情况的验证者提交了错误的输出根。在输出根提交后不久，共有 12 位质疑者对该输出发起了质疑。
其中一位质疑者成功调用了 proveFault 函数，删除了错误的输出。
质疑者成功执行了 proveFault 函数 | 来源：etherscan
这是以太坊 Rollup 主网历史上首次成功的质疑案例。这也是自 2021 年 5 月第一个 Optimistic Rollup（Arbitrum）推出约三年后，首次在主网环境中成功验证和质疑故障证明的案例。有关该质疑的详细概述可参见 Kroma 撰写的文章。在这个案例中，Kroma 链并未进行回滚，只是删除了不正确的输出根。
免责声明：欺诈证明还是故障证明？
欺诈证明也被称为故障证明。特别是在 Optimism 和 OP Stack 链中，使用的是“故障证明”这一术语，而在 Arbitrum、Cartesi、L2Beat 等项目中，使用的术语是“欺诈证明”。
考虑到上述 Kroma 质疑案例，可以推断出质疑往往源自于“错误”，而非恶意试图操纵提现。在上述案例中，主要原因是 Kroma 验证者观察到的 L1 客户端异常。换句话说，质疑有时仅仅是由于验证者的错误或补丁不当引发的。在这种情况下，使用“故障证明”这个术语可能更为合适。
然而，更能反映其目的的术语是“欺诈证明”。迄今为止引入的所有机制，以及未来将引入的机制，都是为了验证通过恶意输出试图窃取桥内资金的“欺诈行为”。
重点是，虽然目的是防止欺诈，但实际上质疑可能是由错误引发的。在本文中，我将使用“欺诈证明”，这一术语在生态系统中使用更广泛。
3. 黑客攻击！ - 利用欺诈证明机制
3.1. 设计经济争议协议
每个 Optimistic Rollup 都实施了自己的欺诈证明和质疑机制，以保护用户资金。这些机制的共同目标是“只要有至少一个诚实的参与者，协议就能保持安全”。欺诈证明是描述预定的状态转换函数已被正确执行的证明，通过验证过程，最终会产生诚实参与者获胜的结果。
然而，这并不总是成立。实际上，即使有诚实的参与者存在，也可能会出现协议陷入危险的情况。例如，由于欺诈证明很复杂，可能会出现意想不到的漏洞，而恶意参与者可能因为激励机制不对齐而比诚实参与者获得经济上的优势，导致用户提现大幅延迟或资金被盗。
因此，设计欺诈证明和质疑机制是一项非常困难的任务。特别是，要成为阶段2 Rollup，质疑机制必须是完美的，并且要有应对各种攻击向量和漏洞的对策。
换句话说，每个欺诈证明和质疑机制都需要考虑如何应对攻击向量。如果不了解每个攻击向量，就无法理解为什么协议必须以这种方式设计。
因此，在本节中，我们将首先研究以下攻击向量，并探索各协议如何应对这些攻击：
注意：以下讨论的攻击向量都是公开已知的，并且不会影响任何主网的安全性。
接下来的章节将分析的各协议及其各自的特点如下：
3.2. 攻击向量 #1：利用经济争议游戏
大多数实施了欺诈证明机制的乐观 Rollup 都要求进行二分法，以找出第一个不一致的点。协议必须提供激励，鼓励参与者诚实行事，这是非常重要的。
实现这一目标的最简单方法之一是让参与者在采取行动时抵押一定金额的资金（保证金），如果他们被认为恶意行为，则会被罚没保证金。
从博弈论的角度来看，协议必须确保恶意参与者为攻击所消耗的资金大于诚实参与者为防御所消耗的资金。然而，这非常难以实现。
这里的关键原因在于，在博弈的环境中，在未完成质疑之前，无法事先知道谁是恶意参与者。换句话说，提交输出的断言者可能是恶意的，质疑输出的质疑者也可能是恶意的。因此，协议必须在假设任一方可能是恶意的基础上进行设计。此外，由于可能存在各种攻击向量，设计协议变得极为复杂。
由于每个协议采用不同的机制，因此必须定义与每种方法对应的攻击向量和攻击者的激励模型。此外，必须设计一个经济安全模型，以确保即使在这些模型结合时仍能保持安全。
这个话题仍在持续探讨中。在本节中，我们将分析可能普遍发生的攻击向量，以及参与者在这些场景中的激励。此外，我们还将探讨每个协议如何应对这些攻击，以及它们在多大程度上限制此类激励。
3.2.1. 攻击向量 #1-1：延迟攻击
延迟攻击是指恶意实体并不旨在窃取 Rollup 资金，而是阻止或延迟输出在 L1 上的确认。这种攻击可以在大多数当前的 Optimistic Rollup 中发生，增加提款的额外延迟，使用户从 L1 提款超过一周。
这与由于 L1 验证者的审查而引起的攻击稍有不同，后者将稍后讨论。审查阻止诚实参与者在以太坊上采取任何行动，从而允许恶意状态根被最终确认。另一方面，延迟攻击即使在诚实参与者积极参与的情况下，也可以延迟状态根的最终确认。在这种情况下，用户的提款不仅可能被延迟，而且如果攻击者的资金多于防御者，恶意状态根可能会被最终确认，从而导致用户资金被盗。
防止延迟攻击的最简单方法之一是要求质疑系统中的参与者抵押一定金额的资金或保证金，如果他们被认为造成延迟，则可以罚没该保证金。
然而，需要考虑一些因素。如果攻击者不怕资金被罚没，仍然试图进行延迟攻击，该怎么办？
这个攻击向量相当棘手。这也是为什么 Arbitrum 的欺诈证明系统目前在许可结构中运行的原因。
应用于 Arbitrum One 和 Arbitrum Classic 的欺诈证明机制采用了分支模型。与其简单地允许参与者质疑不正确的声明，不如每个参与者提交他们认为正确的声明，并附上一定金额的资金，将这些视为“链的分叉”。声明也可以被视为链状态上的检查点。
Arbitrum 的分支模型
在 Arbitrum Classic 中，参与者将提交他们认为正确的声明和链分支，通过质疑逐步删除不正确的链分支，最终确认正确的声明。
然而，单次质疑并不能确定谁是正确的。两个恶意参与者可能以错误的方式进行二分法，将无关的点定义为不一致点，从而排除正确的声明。因此，Arbitrum 确保质疑持续进行，直到没有参与者在特定声明上抵押资金，从而保证如果至少有一个诚实参与者，则质疑能够成功解决。
这可以被恶意利用进行延迟攻击。假设有诚实参与者和 N-1 个恶意攻击者在正确的声明上抵押资金，而一个攻击者在错误的声明上抵押资金。如果攻击者能够始终在诚实参与者之前提交他们的交易，他们就可以首先发起质疑。在最坏的情况下，如果他们错误地进行二分，分割他们一致的部分而不是不一致的部分，他们就可以在错误的部分提交欺诈证明。自然，这将会通过，导致在正确声明上抵押资金的一方失败。
由于每个质疑可能需要长达 7 天的时间，攻击者可以将协议的延迟时间延长至 7 * (N-1) 天。
Arbitrum Classic 的延迟攻击 | 来源：L2Beat Medium
这个机制的问题在于，延迟攻击的成本与协议延迟的时间呈线性增长。如果攻击者发现这种攻击是可盈利的，他们会想要尽可能延长协议的延迟时间，而总延迟时间将与攻击者的资金总额成正比，这可能导致用户提款的延迟时间非常长。
总之，一个能够有效防御延迟攻击的欺诈证明协议，必须设计成那种可使得最大延迟时间被限制在一定范围内，或者延迟的执行成本随时间呈指数增长的机制，从而使得执行攻击的成本大于攻击的激励。
3.2.2. 攻击向量 #1-2：Sybil 攻击（资源耗尽攻击）
另一个攻击向量是 Sybil 攻击（资源耗尽攻击，鲸鱼攻击）。当攻击者的资金或计算资源超过防御者时，就会发生这种情况。攻击者可以不断提交不正确的输出根或创建无意义的质疑，耗尽防御者的资金或计算资源。在某个时刻，防御者将耗尽资金或空闲的计算资源，从而无法进行防御，而攻击者将最终确定不正确的输出根并窃取资金。
通常，上述攻击向量可以在无许可系统中通过以下两种方式发生：
为了防止此类攻击，必须合理设计防御者对攻击者的优势。在所有情况下，防御者必须对攻击者具有足够的优势。做到这一点的一种方法是仔细设计抵押金；由于 Sybil 攻击与每个参与者可用的资金总额有关，如果抵押金设定得当，应该可以确定“系统在攻击者的总资金未超过防御者的总资金 N 倍的情况下是安全的”。
防止 Sybil 攻击的另一种已知方法是实施抗 Sybil 的争议协议。在接下来的章节中，我们将进一步介绍 Cartesi Dave。
让我们看看每个协议如何通过各自的设计来应对这些延迟和 Sybil 攻击。
3.3. 解决方案 #1：经济健全的争议游戏
1） Arbitrum BoLD
BoLD 在 Arbitrum Classic 的分支模型基础上，引入了以下三个元素以防止延迟攻击的漏洞：
所有对所有质疑机制。在 BoLD 中，质疑不再是逐对进行，而是采用所有参与者可以在他们同意的分支上抵押资金的并发所有对所有系统。这防止了之前1对1逐个质疑所产生的延迟攻击向量，并确保对同一争议无法发生多个独立的质疑。
通过正确状态计算的证明防止恶意二分（历史承诺）。在 Arbitrum Classic 中的问题是，恶意参与者可以通过以错误的方式进行二分，故意造成延迟，将无争议部分标记为争议点。为此，BoLD 要求提交证明，与状态根一起，验证状态根在二分过程中被正确计算，确保没有发生恶意二分。
在 BoLD 中，参与者必须在二分过程中提交证明与状态根。这一证明验证当前状态根是否是基于之前提交的状态根正确计算的。如果恶意参与者试图在二分过程中提交与之前提交的状态根无关的任意根，证明验证将失败，导致二分交易失败。这有效地确保每个声明只能发生一种类型的二分。
因此，如果攻击者想在 BoLD 中对诚实声明进行多次二分，他们必须提交多个声明。
然而，生成这个证明需要验证者使用相当多的计算资源。在内部，生成这个证明需要为二分中的所有状态生成哈希，在 Arbitrum 中通常估计大约需要 270 个哈希（大约 1.18 x 10²¹）。为了解决这个问题，BoLD 将质疑分为三个级别，减少需要计算的哈希数量至 226（大约 6.71 x 10⁷）。
（此图假设总共有269条指令，实际数据可能有所不同）
在之前的 Arbitrum Classic 中，质疑的持续时间没有时间限制，允许恶意参与者只要资金充足，就可以无限期延迟协议。BoLD 引入了一种棋钟机制，有效地限制质疑的持续时间。
假设有两个参与者提交了不同的声明。每个参与者都有一个计时器（棋钟），时间为 6.4 天。当轮到某个参与者提交二分或证明时，计时器开始倒计时，并在参与者完成任务后停止。
由于每个参与者都有 6.4 天的时间，因此单个参与者能延迟进程的最大时间为 6.4 天。因此，在 BoLD 中，质疑的最长持续时间为 12.8 天（在某些情况下，当安全委员会介入时，额外增加 2 天）。
通过这些机制，Arbitrum BoLD 有效限制了由质疑引起的延迟。质疑的最大持续时间为两周，用户可能经历的最大额外延迟约为一周。
然而，这可能被利用来进行延迟攻击。恶意参与者可以创建一个质疑，并与 L1 验证者合谋，审查 Arbitrum 上的诚实验证者，从而将 Arbitrum 用户的提款延迟长达一周。在这种情况下，在此时间段内请求提款的用户可能会因为资金被锁定而面临机会成本。尽管这不是攻击者直接从资金中获利的攻击，但由于对用户造成了机会成本，仍然应该予以防止。Arbitrum BoLD 正在通过将创建质疑所需的抵押金设置得足够高来应对这一问题，以威慑此类攻击。
Arbitrum 在 BoLD 的经济文件中计算了这个金额。协议延迟的主要原因是 L1 验证者的审查。在延迟攻击的情况下，情景将如下展开：
攻击者的利润来自于向质疑输出请求提款的用户所产生的机会成本。最坏的情况是，所有 Arbitrum 中的资金都在一个输出中请求提款，此时用户所承受的机会成本计算如下，假设 Arbitrum One 的 TVL 为 154 亿美元，APY 为 5%：
机会成本=15,400,000 x (1.051/52 - 1) = $14,722,400
由于提交不正确声明可能带来如此高的机会成本，BoLD 中的声明提交者被要求提交类似量级的抵押金。目前，BoLD 中声明提交所需的抵押金设定为 3600 ETH，约合 940 万美元。
这样做是为了预防攻击者通过延迟给系统造成重大损失。由于攻击者在质疑中将失去其抵押金，他们可以造成最高 1470 万美元的机会成本，但将损失约 940 万美元的资金。因此，BoLD 通过要求抵押金与最坏情况下的机会成本相当来抑制延迟攻击。
然而，3600 ETH 的抵押金并不是仅仅由于延迟攻击而设定的。为了防御 Sybil 攻击，Arbitrum BoLD 可确保系统在攻击者的总资金是防御者总资金的 6.5 倍之前保持安全，这就是 3600 ETH 的抵押金额度的确定依据。
从 Sybil 攻击的角度来看，以下攻击情景可能会在 Arbitrum BoLD 中发生。BoLD 的质疑系统由三个层次组成，用户必须锁定资金以提交他们认为正确的声明。
假设诚实参与者 Alice 提交了一个有效的声明，金额为 X ETH。拥有 3600 ETH 的恶意参与者 Bob 可以创建多个恶意声明。此时，Alice 需要为 Bob 的每个声明在低层锁定 Y ETH。
在 Arbitrum 的分支模型中，锁定资金意味着同意从创世到声明的链状态。这个特性允许参与者将他们抵押的资金从声明 A 移动到其子声明 A' 和 A''。因此，Alice 将她最初抵押的 X ETH 转移到低层，并为 Bob 的每个恶意声明锁定 Y ETH。
如果 Bob 的资金明显多于 Alice，会发生什么？Bob 可以生成无数恶意声明，直到 Alice 的资金耗尽到无法继续锁定。在这一时刻，Alice 将无法继续进行二分，从而允许 Bob 确认不正确的声明。
归根结底，这个问题归结为防御者在游戏中应该比攻击者更优势的程度。
Arbitrum 将这一指标称为资源比例。它表明诚实参与者相对于恶意参与者的优势程度。这个比例通过每个参与者必须支付的 gas 费 (G) 和抵押金额 (S) 的比例来表示，如下所示：
BoLD 的质疑系统分为三个层次，通过在每个层次上保持这一资源比例，确保防御者在整个系统中始终比攻击者具有 N 倍的优势。Arbitrum 根据这一资源比例计算了顶层所需的抵押金量并绘制了图表。
（顶层争议抵押成本与 Arbitrum BoLD 的资源比例 | 来源：Desmos）
根据该图，当资源比例为 100 倍时，顶层所需的抵押金超过 100 万 ETH（超过 4 万亿美元）。虽然更高的资源比例使系统在防止 Sybil 攻击方面更加安全，但抵押金额却变得如此高，以至于几乎没有人能参与系统，这使得它与仅有一个验证者提交声明的中心化系统没有区别。
因此，在 BoLD 中，资源比例设定为 6.5 倍，使得顶层的抵押金为 3600 ETH，一级和二级的抵押金分别设定为 555 ETH 和 79 ETH。
总之，BoLD 通过计算资源比例并设定抵押金额，确保防御者比攻击者有 6.5 倍的优势，以防止 Sybil 攻击。
2）Cartesi Dave
Cartesi 的 Dave 于 2022 年 12 月在一篇名为《非许可评审锦标赛》的论文中首次提出，早于 BoLD 的首份白皮书。它旨在使诚实参与者的计算资源和资金相对于攻击者保持优势。Dave 的结构与 BoLD 类似，具有两个关键特征：
通过正确状态计算证明（历史承诺）防止恶意二分。
与 BoLD 类似，Dave 要求参与者在二分过程中生成证明，以显示他们正确地进行了计算，从而防止恶意形式的二分。因此，Dave 的质疑系统也分为多个层次，以节省验证者的资源。
在锦标赛结构中采用一对一的顺序质疑机制。
Dave 的质疑不是一次性进行的，而是以锦标赛的形式进行，具体如下面的图所示。
上图展示了当恶意攻击者提交七个错误声明对网络进行质疑时，质疑是如何进行的。由于历史承诺的性质，支持正确声明（以绿色表示）的诚实参与者被聚集在一起组成一个团队。在 Dave 中，他们被组织成锦标赛形式，并按图示排列，每个参与者进行一对一的质疑。同一阶段的质疑是并行进行的，经过一周，当质疑完成后，胜者将进入下一个阶段。在图中，诚实参与者的团队必须经历三轮质疑才能赢得锦标赛。
这一特性在防止 Sybil 攻击方面非常有效。首先，攻击者必须创建多个声明来执行 Sybil 攻击，每个声明都会显著消耗攻击者的计算资源和资金。
Cartesi 的论文证明，在任何情况下，防御者始终保持对攻击者的指数优势。换句话说，Dave 确保可以用对攻击者数量的对数资源来防御 Sybil 攻击。这使得在 Dave 中执行 Sybil 攻击变得非常困难，因此 Dave 的抵押金额被设定为最低 1 ETH，远低于 BoLD 中的金额。
然而，Dave 很容易受到延迟攻击。锦标赛的每个阶段消耗一个单位的质疑时间（一个星期），因此恶意声明越多，协议延迟就越长。在 Dave 中完全解决一个质疑所需的时间可以用以下公式表示：
Td = 7 x log2(1 + NA)(天数)
其中 NAN_ANA 表示恶意声明的数量。然而，Dave 的质疑可以由多个层级组成，以有效生成历史承诺。在这里，恶意参与者可以在每个质疑层级生成 NAN_ANA 个恶意声明，这将增加总延迟时间，如下所示：
Td = 7 x [log2(1 + NA)]L(天数)
其中 LLL 表示每个质疑中的层级数量。如果如上图所示，有七个恶意声明且 L=2，则完全解决质疑可能需要长达 9 周，用户将经历额外的 2 个月的提款延迟。如果层级数量增加或恶意声明数量增加，延迟可能会延长至几个月。
Cartesi 旨在利用零知识证明（ZK）解决此问题，详细讨论将在第 4 节“可行的改进”中进行。
3）乐观故障证明（Optimism Fault Proof, OPFP）
OPFP 是一个非许可质疑协议，目前在 OP 主网应用，具有以下特点：
OPFP 允许任何人随时提交输出（根声明）。不同意所提交输出的验证者可以通过发起二分过程来对其进行质疑。
OPFP 博弈树和二分过程的架构 | 来源：Optimism 文件
二分过程是在上图所示的博弈树上并发进行的。树的叶子表示 L2 的状态，树中的每个节点对应 L2 中的一个状态，最右侧的叶子表示最新的 L2 状态。例如，在节点 1 提交声明与在节点 31 提交状态是等效的。
这种结构允许表示二分。例如，如果一个验证者不同意根声明（节点 1），他们会在节点 2 提交声明，节点 2 对应树中的节点 23，因为它是节点 16 和节点 31 之间的中点。节点 1 的提交者接着会检查节点 23 的 L2 状态，如果同意，则提交节点 6（节点 27）；如果不同意，则提交节点 4（节点 19），继续这个过程直到找到分歧。
即使在一个博弈中存在多个二分方向，它们也可以同时进行，并且任何人都可以参与二分过程，而不仅仅是输出提交者。
OPFP 博弈树的完整架构 | 来源：Optimism 文件
OPFP 中使用的博弈树是嵌套结构，上层树处理区块级别的二分，而下层子树处理指令级别的二分。
与 BoLD 或 Dave 不同，OPFP 并不通过历史承诺来强制执行正确的二分，因为生成和提交此类承诺的链下/链上成本较高。
基于模块化的可定制争议游戏 目前，OP 主网仅上线了两种类型的争议游戏（非许可/许可）。Optimism 旨在最终引入各种类型的争议游戏，并已实现支持此目标的最小接口。通过遵循指定的函数名称和参数，可以创建自定义的争议游戏。
通过棋钟限制质疑时间
在 OPFP 中，当发生质疑时，提出者和质疑者都会获得一个时钟，分配用于二分的时间。每次提出声明时，时钟就开始对对方计时。Optimism 称之为“继承祖父的时钟”。
有趣的是，每个参与者都允许有 3.5 天而不是 7 天的时间，这意味着如果没有人对输出提出质疑，该输出将在 3.5 天内最终确定。
然而，这并不允许立即提现。在输出最终确定后，OPFP 有一个为期 3.5 天的守护期，在此期间，安全委员会可以干预并在必要时使不正确的输出失效。
用户在“快乐路径”中的提款流程 | 来源：OP Labs 博客
基于这些机制，OPFP 和其他乐观汇总（optimistic rollups）一样，保证用户在提交后至少可以在 7 天后进行提现。然而，如果发生质疑，用户可能需要超过 7 天才能通过该输出进行提现。OPFP 的棋钟模型限制了每个参与者在二分过程上可以花费的时间，但并没有严格限制质疑解决之前的总时间。
这就引出了一个问题：如果 OPFP 上发生质疑，用户的提款是否可能被延迟超过一周，类似于 BoLD 的情况？答案是“是的”。与 BoLD 或 Dave 不同，Optimism 为用户提供了应对质疑情况的选项，这基于协议的独特特性。
OPFP 在假设“提交不正确声明的参与者将失去其保证金”的基础上运作。然而，OPFP 中存在一个边缘案例，使得这一假设被打破，这被称为“搭便车声明”。这种情况可能发生在以下场景中：
此时，Alice 应该回应并申领 Bob 的保证金，但她继承了 Bob 时钟上剩余的时间，这可能不足以让她反驳他的声明。因此，Bob 可能通过提交“搭便车声明”来避免失去他的保证金。
Optimism Fault Proof 中的搭便车声明 | 来源：L2Beat
虽然这并不妨碍质疑得到正确解决，但确实代表了一种情况，即“提交了一个不正确的声明而未罚没保证金”，从激励的角度来看，这种情况应该被避免的。
因此，如果提议者或质疑者的剩余时间低于 3 小时，OPFP 通过将时钟重置为 3 小时来解决这个问题。这确保了有足够的时间来反驳搭便车声明。然而，如果在接下来的二分期内没有采取行动超过 3 小时，质疑将结束。
我们可以想象一个场景，在这个场景中，这个机制被用来进行延迟攻击。假设诚实的参与者 Alice 提交了一个正确的输出，从 Alice 提交的那一刻起，质疑者的时钟开始计时。恶意参与者 Bob 等到质疑者的时钟到期前 1 秒提交一个不正确的输出。此时，OPFP 的规则将 Bob 的时间延长至 3 小时。Alice 会回应，而 Bob 会继续利用为每次二分提供的额外 3 小时。
这可能会延迟质疑的解决。Bob 能够延迟的最长时间为 3.5 天 + 3 小时 × 最大的二分次数。OPFP 的 MAX_GAME_DEPTH 为 73，这意味着 Bob 最长可以将流程延迟 3.5 天 + 3 小时 × 36 = 8 天。如果 Alice 也采取类似措施来延迟质疑，则二分过程可能需要 16 天。
这是否意味着用户无法在 16 天内提现？实际上并非如此，因为 Optimism 的提款逻辑使得这种情况不成立。与 Arbitrum 不同，后者要求提款必须证明包含在特定的 L2 区块中，OP Stack 使用一种存储证明机制，提现请求记录在 L2 的 L2ToL1MessagePasser 合约中。这意味着即使特定输出的质疑时间很长，用户仍然可以等待下一个输出完成，并根据该输出中包含的合约存储根进行提现。因此，即使他们请求的提现区块受到质疑，用户也不必经历长时间的延迟，因为他们可以使用下一个输出。
然而，这一切仅在用户迅速行动的情况下成立。在大多数情况下，用户可能仍会经历几天的延迟。这可以归因于 OP Stack 中的提现流程，主要包括以下三个步骤：
关键点在于，从证明提现到最终完成提现，用户必须等待一周。如果 Alice 在输出 B 上证明了她的提现，并且发生了质疑，她可以为输出 C 发送另一个证明，并在一周后完成提现。在这种情况下，Alice 只会经历输出 B 和输出 C 之间的延迟。
因此，那些未意识到质疑的创建或响应较晚的用户，可能会经历最多 9 天的额外提现延迟。
此外，OPFP 中还有一个额外的延迟攻击向量，即每个输出都得到连续质疑。在这种情况下，用户无法通过在下一个输出上证明来绕过延迟，导致整个协议被延迟。OPFP 通过要求参与者在每个二分级别质押保证金来应对这一点，保证金金额呈指数级增加，如下图所示。
OPFP 保证金金额 | 来源：Optimism 文件
换句话说，攻击者在 OPFP 中试图延迟质疑解决的时间越长，所需的保证金成本就会越高，因为保证金要求是呈指数增长的，这减少了随时间进行延迟攻击的激励。此外，由于 OPFP 中的输出可以随时提交，攻击者很难估算进行延迟攻击所需的资源。初始保证金设定为 0.08 ETH，而在全面质疑时必须提交的总保证金高达 ~700 ETH。
总之，OPFP 在单次质疑的情况下将延迟的时长留给用户的决定，并使用指数型保证金要求来抵消因连续质疑造成的延迟攻击。然而，OPFP 很容易受到 Sybil 的攻击。在 OPFP 中，如果攻击者的资金比防御者多，则可能会发生 Sybil 攻击。
在 OPFP 中可能存在以下 Sybil 攻击向量，均可能导致用户资金被盗：
这在 OPFP 中是可能的，因为在整个质疑过程中，攻击者和防御者所需的总保证金金额几乎相同，且防御者所使用的资源（例如，Gas费或算力）并没有显著少于攻击者。
然而，这并不意味着当前 OP 主网中的用户资金处于风险之中。OPFP 仍处于阶段1，安全委员会有权纠正任何不当结果。因此，即使发生此类攻击，安全委员会也可以介入，保护 OP 主网桥上的用户资金。
不过，为了将 OPFP 移至阶段2，Optimism 必须修改机制，以确保防御者相对于攻击者具有更大的优势。Optimism 正在准备争议游戏 V2 来解决这个问题，更多细节将在第 4 节“可行的改进”中介绍。
4) Kroma ZK 故障证明 (Kroma ZKFP)
Kroma 是基于 OP Stack 的 L2，在 OPFP 引入之前，它于 2023 年 9 月在其主网上推出了一种无许可的 ZK 故障证明系统。Kroma ZKFP 具有与 OPFP 相似的特征，但突出的地方在于它使用 ZK 生成区块级证明，并利用分解而非二分，大大减少了挑战过程所需的交互次数。Kroma ZKFP 的主要特点总结如下：
通过 ZK 和分解减少交互次数
Kroma ZKFP 允许参与者在四次交互内找到分歧点。当发起质疑时，Kroma ZKFP 在 1,800 个区块上处理质疑，从之前的输出到当前的输出。与二分法不同，在二分法中范围被分成两半，而在分解中，提议者和质疑者将范围分成 N 部分。该过程如下：
在每位参与者提交两笔交易后，他们将确定出他们存在分歧的区块，质疑者可以生成一个 ZK 故障证明，以表明提议者的主张是错误的。在 Kroma ZKFP 中，二分超时设置为 1 小时，而 ZK 证明生成的超时为 8 小时。
BoLD 和 OPFP 都为质疑赢家提供了激励，但并未为输出提交者提供具体的激励，实际上，任何想要提取资金的人都可以提交输出并成为验证者。然而，对于希望提现的用户而言，自行操作验证者客户端是不切实际的，并且必须有人定期提交输出以保持活跃性。由于这是一个资源密集型的任务，需要支付Gas费来提交输出和运营验证者客户端，因此如果没有适当的激励，只有少数人可能参与作为验证者，这可能导致中心化以及在故障场景中的响应不足。
为此，Kroma 修改了 OP Stack，将链上产生的Gas费的一半分配给提交输出的验证者。此外，Kroma 计划在 TGE 之后将这一奖励机制过渡到其原生代币 KRO，并旨在引入类似 DPoS 的验证者系统，使普通用户能够在不运行自己客户端的情况下为链的安全性和活跃性做出贡献。
Kroma 中的保证金金额目前设置为 0.2 ETH，确保其大于生成 ZK 证明和进行二分的成本。这项保证金将在未来的验证者系统中转变为 KRO 的质押。
为了确保激励公平且一致地分配，Kroma 将输出提交间隔固定为 1 小时，并从预注册的验证者集合中随机选择验证者作为提议者。这防止了过度竞争导致Gas费浪费的情况，并避免了拥有交易排序权的区块构建者垄断奖励的情况。
由于这一机制，Kroma ZKFP 运行并发的 1 对 1 质疑系统。当随机选择的验证者提交输出时，任何人都可以发起质疑，二分仅在输出提交者和质疑者之间进行。多个质疑可以同时进行，首个提交有效 ZK 证明的质疑者将赢得质疑。
严格设定的超时意味着，即使是试图进行延迟攻击的恶意质疑者也必须在 10 小时内完成所有的二分和证明生成。此外，由于质疑者被迫在 6 天内完成所有操作（不包括 1 天的监护期），是不可能在 Kroma 中进行一般的延迟攻击。
然而，如果攻击者的资金超过防御者，Kroma ZKFP 仍将容易受到 Sybil 攻击，类似于 OPFP。在 Kroma ZKFP 中，Sybil 攻击的情景可能如下所示：
与 OPFP 类似，Kroma ZKFP 在成功质疑后会删除相应的输出。因此，如果发生这样的攻击，该输出可能会被删除，导致用户提取资金的延迟达 1 小时。如果攻击持续进行，所有诚实的验证者可能会耗尽资金，导致错误输出最终确认，从而使攻击者能够窃取用户资金。
此外，Kroma ZKFP 仍处于阶段0，其证明系统尚不完善，原因如下：
在 OPFP 中，二分的起点通常是大约一周前的最后确认输出。然而，在 Kroma ZKFP 中，起点是最后提交的输出，该输出大约在 1 小时前提交，二分过程在 1,800 个区块上进行。
这可能使质疑者在先前的输出因质疑被删除的情况下赢得质疑。在这种情况下，二分将基于质疑者提交的先前输出信息进行，如果质疑者恶意操控这些信息，他们可能会赢得质疑。
虽然 Kroma ZKFP 使用 ZK 确保如果 ZK 电路没有漏洞，则不可能最终确认错误的状态转移，但 Kroma ZKFP 并未验证 ZK 证明生成是否基于正确的批数据。这意味着，即使某些交易被排除或错误的交易被纳入批处理中，ZK 证明仍然有可能通过验证。
因此，有可能通过使用基于错误数据的 ZK 证明赢得质疑，并且如果用户的提现交易被排除在批处理之外，他们的提现可能会被延迟。
然而，在实践中，安全委员会可以干预以撤回错误质疑的结果或删除无效输出，因此这些攻击向量不会影响 Kroma 主网用户的资金。然而，要达到阶段2，Kroma ZKFP 必须实施针对这些漏洞的防御机制。Kroma 已经提出了针对这些问题的改进方案，具体将在第 4 节“可行的改进”中详细介绍。
3.4 攻击向量 #2：L1 审查
之前我们提到，Rollup 继承了以太坊的安全性。这意味着，如果以太坊的安全性受到损害，Rollup 也会受到影响。
以太坊的情况可能影响 Rollup 安全性的两种情形：
这些基于审查的攻击在 Rollup 层面上很难应对，因为它们发生在以太坊协议层，需要对以太坊本身进行改进。然而，Rollup 在此期间可以采用一些策略。
3.5 解决方案 #2：7 天提现延迟和半自动化的 51% 攻击恢复
为应对这些攻击向量，Optimistic Rollup 当前实施了 7 天的提现延迟。这 7 天的时间最初是由 Vitalik 提出的，是基于 7 天“足够”应对审查攻击的想法。
让我们分析一下 Optimistic Rollup 的 7 天质疑期是否足以抵御审查攻击，将考虑两种类型的审查：弱审查和强审查攻击。
对于第一种弱审查，我们可以使用概率计算来查看 7 天的时间是否赋予 Optimistic Rollup 抵抗审查攻击的能力。这涉及计算在某些验证者审查 Rollup 质疑交易时成功质疑欺诈的概率。
在这里，需要考虑两个因素：
为了在 7 天内成功进行质疑，必须有多笔交易成功。
在大多数协议中，如果只有一笔来自诚实参与者的交易在这一周内被纳入，质疑就不会成功。因此，我们需要计算在 7 天内提交欺诈证明所需的所有交易被纳入的概率
必须合理假设涉及审查的验证者的比例。 目前，大多数以太坊区块构建者（已知为中心化）并没有进行审查，考虑到以太坊上单独质押者的比例，绝大多数（例如，99.9%）的验证者合谋进行审查的机会几乎为零。
（以太坊主要区块构建者的审查 | 来源：Justin Drake 的推文）
考虑到这两点，如果我们假设 99.5% 的验证者（仍然是一个过于极端的假设）参与了审查，并计算诚实参与者成功发送 30 到 40 笔交易所需的质疑协议（如 BoLD 或 OPFP）的概率，那么在所有情况下，成功的概率接近 100%。此外，随着未来解决方案（如纳入列表或多个并发提议者，例如 BRAID、APS + FOCIL）的出现，抵抗审查的能力可能会进一步增强，从而降低 Optimistic Rollup 因弱审查而损失用户资金的风险。
那么，在强审查的情况下，7 天是否足够？前面提到的 51% 攻击只能通过社交分叉来解决。不可归因审查攻击尤其难以检测，无法通过针对弱审查设计的解决方案（如纳入列表）来防止。
有一个提议是在客户端软件中开发一个半自动化的 51% 攻击恢复工具，这基于 Vitalik 提出的结构。以太坊研究人员进一步开发了这一审查检测解决方案，分为两个步骤：
假设该工具检测到 51% 攻击，下一步将是通过社交分叉转移到一个新链上，从而使攻击者的资金无效。
在这种情况下，受 51% 攻击影响的资金必须保持锁定，直到社交分叉执行完成。在 The DAO 硬分叉期间就发生过类似的情况，黑客的资金在子 DAO 中锁定了 27 天，直到他们能够提现。在此期间，以太坊社区成功进行了硬分叉，阻止了黑客兑现资金（有关更多细节，请参见 Vitalik 在 Reddit 上发布的帖子）。
换句话说，即使发生 51% 攻击，资金也需要保持锁定，直到进行社交分叉。在这种情况下，Optimistic Rollup 中的 7 天提现期充当了缓冲区。如果在这一周内没有进行社交分叉，Optimistic Rollup 中的用户资金可能会被盗，也可能提现到中心化交易所，或通过 Tornado Cash 混合，致使资金几乎无法在社交分叉后返回给用户。
总而言之，虽然 Optimistic Rollup 中的 7 天提现期最初是为了应对弱审查，但实际上，弱审查发生的可能性不大，而这 7 天的时间在强审查需要社交分叉的情况下则充当了缓冲时间。
从这个角度来看，有人批评 OPFP 将此期限缩短至 3.5 天，使其更容易受到强审查攻击。然而，这种批评是没有根据的。由于 Optimism 仍处于阶段1，监护人有足够的缓冲期来验证状态根的正确性，提现只能在额外的 3.5 天监护期结束后进行。因此，即使发生强审查攻击，攻击者仍需等待 7 天才能提现。此外，攻击者还必须在整整一周内审查所有与质疑相关的交易才能成功，因为监护人也需要被审查，以防止他们中止对恶意输出的确认。
然而，关键在于以太坊必须确保能够在 7 天内处理社交分叉。这意味着检测 51% 攻击的工具必须准备就绪，并且需要进行充分的研究和模拟，以确定是否能够在 7 天内实施社交分叉。只有在此情况下，Optimistic Rollup 中的 7 天提现延迟才能被视为有效的保障。
3.6 攻击向量 #3：利用欺诈证明系统中的漏洞
大多数质疑协议通过让参与者找到一个特定的点（指令或区块），在该点上他们的意见不一致，然后生成证明，表明另一位参与者的主张是错误的。用于生成此证明的虚拟机称为欺诈证明虚拟机（Fraud Proof VM），而在该虚拟机上用于生成证明的软件称为程序（program）。每个协议使用不同的欺诈证明虚拟机和程序，如下所示：
每个欺诈证明系统都为了证明 EVM 中某一特定执行结果在链上是正确的。但是，如果该系统（无论是虚拟机还是程序）中存在漏洞，会发生什么呢？
这个问题可以通过 Yoav Weiss 在 OVM 中发现的攻击向量进行探讨。由于 OVM 的回滚功能存在漏洞，导致攻击成为可能，但创建“欺诈交易”的前提对于攻击的实施至关重要。欺诈交易是在 Rollup 上正常处理时执行的交易，但在使用欺诈证明虚拟机和程序进行质疑时会产生不同结果的交易。由于欺诈证明系统应该生成与 EVM 相同的结果，因此能够创建欺诈交易意味着欺诈证明系统中存在漏洞。
Yoav 发现了 OVM 的欺诈证明系统中的多个漏洞，并能够通过生成欺诈交易来模拟这一攻击。他发现的简单攻击示例是：在 OVM 的 StateManager 中，操作码 SSTORE 和 SLOAD（用于存储和读取状态）的 gas 成本被错误记录。这意味着任何存储或读取合约中值的交易（几乎所有交易，除了简单的 ETH 转账）在质疑过程中都会被标识为欺诈交易，即使它在 Rollup 上正确执行。
简而言之，如果系统中存在漏洞，正确执行的状态更改可能在质疑期间被错误标记为无效，导致诚实参与者提交的输出被标记为错误。
这也是 OP Mainnet 最近将其故障证明系统从无许可模式转变为仅授权参与者可加入的模式的原因之一。在 OPFP 应用到主网后，安全审计披露了欺诈证明系统（Cannon 和 op-program）以及争议游戏挑战协议中的几个漏洞。为了防止系统被利用，Optimism 于 8 月 17 日宣布将切换到一个权限系统。
当然，利用虚拟机漏洞对处于阶段0或阶段1的 Rollup 可能没有重大影响，因为安全委员会可以随时介入以纠正质疑的结果。这是 OP Labs 之前提出的观点。实际上，OP Labs 在 Optimism 论坛中分享了其审计框架，概述了在何种情况下需要进行外部审计的标准。
(OP Labs 审计框架 | 来源：Optimism 论坛)
在这个框架中，最近的情况属于第四象限：“在辅助阶段故障证明”。虽然这些情况与链的安全性相关，但并不直接影响用户资金，因此不包括在审计范围内。这意味着即使漏洞被利用，安全委员会仍然可以纠正结果。
然而，既然已经识别出漏洞，就需要解决这些问题。Optimism 在其 Granite 网络升级中修复了这些问题，使 OP Mainnet 能够恢复到阶段1。
另一方面，系统中的漏洞在阶段2的 Rollup 中可能是致命的。在阶段2，安全委员会只能在可在链上证明的漏洞情况下进行干预。由于在链上证明“质疑结果因系统漏洞而错误”几乎是不可能的，因此如果在阶段2的 Rollup 中发生漏洞，用户的资金可能会面临风险。
3.7 解决方案 #3：多重证明
为了防止此类问题，在代码投入生产之前进行全面审计至关重要。然而，欺诈证明虚拟机和程序是复杂的软件系统，系统越复杂，出现漏洞的可能性就越大。因此，即使经过严格的审计，漏洞仍然可能出现。我们需要探索审计以外的额外策略。
一种方法是，在同一系统内使用多个证明系统。在质疑过程中，系统不仅仅使用单一系统生成欺诈证明，而是可以同时使用不同的虚拟机和程序生成多个欺诈证明，然后对结果进行比较。这将创建一个即使在发生漏洞的情况下也能保持安全的系统。
例如，想象一个同时使用 Optimism 的 Cannon 和 asterisc ZK 故障证明虚拟机（采用 Risc-V）的多重证明系统。在质疑的情况下，以下情况将发生：
如果检测到错误输出，质疑者生成质疑并发起二分法。
一旦通过二分法找到分歧的区块，就会同时发生两个子游戏：
使用传统 OPFP 方法的 Cannon 的子游戏。 使用 asterisc 生成 ZK 故障证明的子游戏。
在两个游戏完成后，将验证这两种不同的欺诈证明。
如果两个证明都通过验证，则质疑者胜出；如果两个证明都未通过，则质疑者失败。然而，如果一个通过而另一个未通过，这表明在证明生成过程中某个虚拟机或程序出现了意外的漏洞。
在这种情况下，安全委员会等实体将介入以调整质疑结果。这确保了系统能够保持无漏洞，同时不违反“安全委员会仅能在可在链上证明的漏洞情况下进行干预”的条件。
这是为使 Optimism 达到阶段2所做的持续努力之一。为支持这一点，OPFP 的争议游戏涉及为模块化的，允许自由实现多个欺诈证明系统，并定义最小接口，以支持这一点。
4. 可行的改进
在前面的章节中，我们探讨了 Optimistic Rollup 协议的设计以及在其质疑和欺诈证明验证过程中可能出现的漏洞。本节将讨论每个协议的问题和解决方案，以及欺诈证明系统和 Optimistic Rollup 的未来前景。
4.1 各协议的改进空间
1) Arbitrum BoLD
BoLD 具有健全的经济质疑协议，因为它将最大协议延迟限制为一周，并确保在攻击者的资金超过防御者的 6.5 倍之前能有效防范 Sybil 攻击。然而，BoLD 存在两个显著问题：
第一个问题可以通过 ZK 技术来解决。BoLD 将质疑分为多个级别，以减少历史承诺计算所需的资源。通过使用 ZK，这可以减少到单一级别。
这个概念与 Cartesi 的 Gabriel 提出的 BoLD++ 建议相似。当质疑分为多个级别时，增加资源比例会导致最高级别的押金规模呈指数增长。然而，当使用单一级别时，可以更容易地增加资源比例，从而使协议更能抵抗 Sybil 攻击。
第二个问题，即需要 3,600 ETH 的押金，更难以解决。BoLD 的押金规模不仅是为了应对 Sybil 攻击，也是为了威慑延迟攻击。押金规模是 TVL（总锁仓价值）的函数，即使使用 ZK，也无法显著降低。为了解决这个问题，BoLD 正在实施一种矿池化押金机制，允许多个参与者共同承担押金。
2）Cartesi Dave
Dave 通过其锦标赛结构有效地应对了 Sybil 攻击，但如前所述，它容易收到的延迟攻击。最大延迟时间是包括恶意声明数量 NA 和质押级别数量 L 的函数，其计算公式为： Td = 7 x [log2(1 + NA)]L(天数)
如果 NA = 7 且 L = 3，协议可能会面临长达四个月的延迟，给用户带来明显的不便和损失，因为提现将被延迟。
ZK 可以帮助减轻这个问题。通过将级别 L 固定为 1（如 BoLD++ 中那行），最大延迟时间可以减少为： Td = 7 x log2(1 + NA)(天数)
据报道，Cartesi 正在利用 RISC Zero 的 ZK 技术进行这一改进。然而，仍然存在对这种改进是否足以完全防止延迟攻击的担忧。如果 NA = 7，协议仍可能面临额外的长达两周的延迟，而攻击者的成本仅为 7 ETH 的押金，外加Gas费和链外历史承诺成本。对于锁仓价值较高的链，这种惩罚可能不足以威慑延迟攻击。
（Dave：带有 BoLD 风格的子质疑机制 | 来源：L2Beat Medium）
有一个建议让 Dave 采用 BoLD 风格的质疑机制，每轮进行 8 名参与者的比赛，而不是进行1对1的对决，类似于传统的锦标赛。在这种情况下，延迟时间的计算公式为：
Td = 7 x log8(1 + NA)(天数)
在这种结构下，攻击者需要至少提供 64 ETH 保证金才能将质疑延迟超过两周，总保证金需求为 64 ETH，并且需要承担大量链上和链外的成本。
然而，这种方法的不足之处是削弱了防守者在面对 Sybil 攻击时的优势。虽然 BoLD 提供了一个防守者比攻击者有 N 倍优势的结构，但 Dave 则创造了一种防守者具有远远超出攻击者的指数级优势。
总之，Dave 可以通过使用 ZK 欺诈证明有效限制延迟攻击的向量。虽然应用类似 BoLD 的结构可以提高抵抗延迟攻击的能力，但这可能会导致防守者在面对 Sybil 攻击时的优势降低。
3）Optimism Fault Proof (OPFP)
OPFP 的缺点是容易受到 Sybil 的攻击，因为攻击者和防守者的成本相等。OP Labs 在 争议游戏 V2 中提出了这一问题的解决方案。
与原始 OPFP 不同，后者在每次二分时提交保证金，而争议游戏 V2 只要求参与者在二分开始时提交保证金。此外，争议游戏 V2 引入了二分法，允许参与者在分支点同时提交多个请求，从而在大多数情况下减少互动次数。
（争议游戏 V2 中的分支声明 | 来源：Optimism Specs GitHub）
在之前的 OPFP 中，Sybil 攻击的向量有：
引入分支声明解决了这两个向量问题。首先，诚实参与者在二分过程中不需要提交额外的保证金，而恶意质疑者必须为他们创建的每个新质疑提交押金。如果押金的金额设置得当，攻击者大量创建质疑就变得不可持续。
其次，在争议游戏V2 中，较高层级的保证金金额更大，因此不断提交虚假输出的成本对于攻击者而言高于防守者。
因此，OPFP 可以通过在争议游戏 V2 中引入的分支声明有效应对 Sybil 攻击。
4）Kroma ZK Fault Proof (Kroma ZKFP)
Kroma ZKFP 面临 Sybil 攻击的脆弱性和不完善证明系统这两大挑战。Kroma ZKFP 要想进展到阶段 1，需要解决以下两个问题：
Kroma 计划从 Scroll 的 Halo2 zkEVM 切换到 Succinct SP1 zkVM，以解决这两个问题并推进到阶段 1。
Kroma 预计将修改其质疑过程，使其与 Optimism 的争议游戏接口对齐。这一调整在 Kroma 的标准中有详细说明，它将允许二分的起始点移动到一周前的最后确定输出，从而解决第一个问题。
对于第二个问题，Kroma 将使用基于 ZK 的无信任推导。具体工作方式如下：
（使用 ZK 的无信任推导 | 来源：Lightscale Notion）
想象一下，我们想证明特定的 L2 区块 T 是正确执行的。在生成 ZK 证明之前，我们必须验证区块 T 的交易数据是否基于 L1 批量数据正确构建。
在这里，Kroma 打算通过 ZK 验证批量数据是否从 L1 正确提取。如果数据只是通过 ZK 程序外部的可信 RPC 获取，那么就无法确认批量数据是否被篡改。可以通过生成区块哈希的连接性 ZK 证明来验证程序是否访问了正确的区块并提取了批量数据，这些区块从区块 O（L2 区块 T 的 L1 来源）到区块 C（创建质疑时的 L1 区块）。如果质疑者基于错误的批量数据构造 L2 区块 T，则质疑者提取批量数据所引用的 L1 区块哈希将与实际包含批量数据（包括 T1）的 L1 区块哈希不同，并且它也不会与区块 C 相连接。因此，只要没有哈希冲突，通过 ZK 验证 L1 区块的连接性可以证明质疑者是从正确的批量数据构造了 L2 区块。
Kroma 计划使用 ZK 验证批量数据的准确性，这可以检查从 L1 区块 O 到 C 的区块哈希连接性。如果质疑者基于错误的批量数据构造 L2 区块 T，他们引用的 L1 区块哈希将与包含正确批量的 L1 区块不同，并且不会连接到区块 C。由于没有哈希冲突，质疑过程可以使用这种方法验证正确的批量数据。
通过这些改进，Kroma ZKFP 将能够进入阶段 1。然而，要达到阶段 2，Kroma 需要额外的解决方案来防范 Sybil 攻击，包括将质疑协议改为所有对所有（All-vs-All）并重新设计保证金机制。
4.2. 总结
5. 欺诈证明的未来
5.1. 阶段 2 Rollup - 您的资金是安全的
如上所述，Optimistic Rollups 正在朝着阶段 2 发展。Arbitrum 正在基于 BoLD 努力实现阶段 2。BoLD 的实施方案已经在治理论坛上发布，并获得了大量支持，目前已经在测试网上部署。如果没有发现重大安全问题，Arbitrum 很可能会在今年年底之前通过 BoLD 实现阶段 2。
Optimism 也在努力实现阶段 2。为了让 OP 主网达到阶段 2，必须完成争议游戏 V2，并且需要有多种证明机制支持多重证明。尽管标准仍在完善中，但争议游戏 V2 有效地解决了现有 OPFP 的弱点，提供了强有力的防护，以抵御 Sybil 攻击，使其更接近阶段 2。此外，各种团队，包括 OP Labs、Succinct、Kroma 和 Kakarot，正在积极开发多重证明，投入了大量研发资源来创造多样化的 OP Stack 证明方式。因此，除非出现重大问题，Optimism 预计也将在明年上半年迈向阶段 2。
这两个 Rollup 过渡到阶段 2 可能会对 Rollup 生态系统产生重大影响。Arbitrum 和 Optimism 各自拥有自己的 Rollup 框架，分别是 Arbitrum Orbit 和 OP Stack。它们的阶段 2 过渡意味着所有使用这些框架的 Rollup 也可以转向阶段 2。
因此，从今年年底到明年，用户基础庞大的主要 Rollup，如 Arbitrum、OP 主网和 Base，预计将过渡到阶段 2，继承以太坊的完整安全性。这很可能会平息诸如“Rollup 只是多重签名”或“Rollup 随时可以拿走您的资金”的批评。
5.2. ZK 欺诈证明是未来
大多数讨论的协议都可以通过实施 ZK 欺诈证明获益。例如，将 ZK 应用到 Arbitrum BoLD 中可以提高资源比率，使其对 Sybil 攻击更具抵御能力，而 Cartesi Dave 则可以使其不那么容易受到延迟攻击。OPFP 也在研发中投入了 ZK 以支持多重证明系统，这可能减少保证金金额并提高协议安全性。
值得注意的是，ZK 欺诈证明不仅仅意味着减少验证者之间的交互。较少的交互意味着验证者所需的资源显著减少，从而降低保证金金额，使更多参与者能够加入协议。此外，这也减少了最大可能的延迟，提高了整体协议安全性。
通过这种方式，ZK 欺诈证明在 Optimistic Rollup 的安全性和去中心化方面发挥着关键作用。
5.3. ZK Rollup 表现如何？欺诈证明会变弱吗？
此时，一些读者可能会问： 如果欺诈证明和质疑机制如此复杂，ZK Rollups 是否会是更好的选择？ 在一定程度上，这是正确的。在 ZK Rollups 中，达到阶段 2 不需要考虑复杂的经济因素，用户的资金在 L1 审查事件中不会面临被盗的风险，用户可以在几小时内提取资金。
Optimistic Rollups 向 ZK Rollups 的过渡可能会比预期更快。这是因为 ZK Rollups 的主要缺点——很高的证明生成成本和时间——正在迅速改善。最近，Succinct Labs 推出了 OP Succinct，这是一种基于 OP Stack 的 ZK 版本，提供了一个轻松启动 ZK Rollups 的框架。
OP Succinct 简介 | 来源：Succinct 博客
不过，仍然有几个需要考虑的因素。首先是成本。在 OP Succinct 中，生成一个区块证明的成本约为 $0.005-$0.01，而运行证明器的每月成本估计在 $6,480 到 $12,960 之间。如果链的交易每秒处理量（TPS）较高，这些成本可能会进一步增加。
（各网络证明成本基准 | 来源：Succinct 博客）
例如，在 OP Succinct 的 Base 网络上，每个区块的平均证明生成成本约为 $0.62。根据这个数字计算，月成本将达到 $803,520。这是 Optimistic Rollups 所没有的额外成本，即使 ZK 成本降低，ZK Rollups 的运营成本也始终会高于 Optimistic Rollups。
第二个考虑是对去中心化的影响。在 ZK Rollups 中，验证者需要运行证明器，这比在 Optimisitic Rollups 中运行欺诈证明程序更困难且成本更高。此外，由于 ZK 系统中的证明生成时间较慢，用户无法实时验证交易。虽然更高的硬件标准可以提高证明生成速度，以匹配交易执行速度，但这意味着运行证明器需要高标准的计算环境。理想情况下，任何人都应该能够运行一个节点以确保链的安全，但 ZK 目前还没有达到这个水平。
最后，ZK Rollups 基于高度复杂的数学和密码学，这种复杂性超出了欺诈证明和质疑协议的范围。因此，在可以安全地用于生产前，ZK 系统需要进行广泛的测试。
Arbitrum 正在追求一种结合 ZK 和 Optimistic 方法的混合协议作为其最终目标。该协议主要作为 Optimistic Rollup 运作，仅在需要快速提现时生成 ZK 证明。这对于需要快速在链之间重新平衡资金的场景（例如交易所或跨链桥）非常有用，也有助于实现链之间的互操作性。
总之，目前 Optimistic Rollup 方法似乎是有效的，同时采用 ZK 作为混合方案。但随着 ZK 证明生成成本和速度的持续改善，未来更多的 Optimistic Rollups 可能会认真考虑转向 ZK。
5.4. 欺诈证明仅适用于 Rollup 吗？
我们已经研究了以太坊的 Optimistic Rollups 及其欺诈证明机制。那么，这种欺诈证明还有哪些其他应用场景呢？
Eigenlayer 是一种允许通过再质押出租以太坊安全性的服务。在 Eigenlayer 中，运营商可以根据 Eigenlayer 内的委托合约，存入 ETH 或用户的 LST，并通过选择多个 AVS（主动验证服务）参与验证。通过 Eigenlayer，协议可以轻松构建 AVS，并减少初始验证者的引导成本。
与任何其他区块链一样，AVS 会对成功验证的运营商进行奖励，并且在他们采取恶意行为时必须对其进行惩罚。这就是欺诈证明可以在罚没过程中使用的地方。
AVS 的罚没示例 | 来源：Eigenlayer GitHub**
以桥接 AVS 为例。桥接 AVS 的前提是必须正确地将用户的资金转移到目标链，任何恶意操纵交易的运营商都应受到罚没。如果发生此类操纵，发现不当行为的质疑者可以在争议解决合约中创建一个带有欺诈证明的质疑，声称运营商在桥接操作中执行不当。如果欺诈证明被认为有效，AVS 可以调用 Eigenlayer 中的罚没合约，暂停该运营商的任何奖励。
尽管这一罚没功能在 Eigenlayer 中尚未实施，但他们最近宣布了共享安全模型，计划在下一个版本中包含罚没功能。这将使欺诈证明可以用于罚没。
轻客户端应该能够在不下载区块链所有数据的情况下，验证一个区块是否得到了大多数（超过 67%）验证者的认可。然而，轻客户端很难为每个区块验证所有验证者的签名，并且随着验证者数量的增加，这几乎变得不可能。
在这方面，Celestia 提出了一个有趣的概念。在 Celestia 中，即使大多数验证者是恶意的，它也提出了一种方法，允许单个诚实的全节点告知轻客户端拒绝有缺陷的区块。这个单一的诚实全节点可以通过欺诈证明来保证其“诚实性”。
Celestia 中的欺诈证明有两种类型：
首先，数据的欺诈证明的工作原理如下：Celestia 允许轻节点在不直接下载区块内所有数据的情况下，验证验证者是否持有正确的数据。为了实现这一点，Celestia 使用了一种称为数据可用性抽样（Data Availability Sampling，DAS）的技术。
Celestia 的数据可用性抽样 | 来源：Celestia 文件
Celestia 的验证者将交易数据结构化为一个 k x k 的矩阵，然后使用称为 2D Reed-Solomon 编码的技术将其扩展为 2k x 2k 的矩阵。他们随后计算每行和每列的总共 4k 个默克尔根，并将进一步哈希这些默克尔根的结果包含在区块头中并传播。
仅凭区块头中的默克尔根信息，轻节点就可以验证 Celestia 的验证者是否持有正确的数据。轻节点从 2k x 2k 矩阵中的随机点请求数据，同时从验证者获取对应行和列的默克尔根。如果这些数据能够与区块头中的值进行验证，则可以信任这些验证者持有正确的数据。
然而，一个重要的考虑因素出现了：如果验证者恶意执行 Reed-Solomon 编码呢？Celestia 通过实施一种称为“坏编码欺诈证明”的机制来解决这个问题。如果 Celestia 的全节点在区块恢复过程中发现编码不正确，它会生成一个包含区块高度、错误编码部分和故障证明的欺诈证明，并将其传播给轻节点。轻节点验证该证明，以确认数据确实编码错误，从而停止使用错误的数据。
此外，Celestia 还提出了状态转换的欺诈证明机制。
Celestia 区块的架构 | 来源：Contribution DAO 博客
Celestia 的区块结构包括在各个时间间隔的交易追踪数据。这使得全节点能够轻松构建欺诈证明，轻节点可以在不执行整个区块的情况下检测不正确的状态转换。然而，由于复杂性问题，这一机制尚未在 Celestia 主网上实施。
总之，数据可用性层中的欺诈证明可以在不依赖共识的情况下过滤不正确的数据和状态转换。
将机器学习应用于区块链的主要原因如下：
这里的关键因素是验证机器学习模型是否经过正确训练。然而，机器学习计算高度密集，这使得在区块链运行环境中完全执行这些计算几乎不可能。因此，像 opML 和 zkML 这样的框架应运而生，以有效验证区块链环境中的机器学习模型训练。opML 采用乐观的方法进行模型训练，将结果记录在区块链上，并通过质疑机制纠正错误。
让我们更仔细地看看 ORA 提出的这一方法，ORA 是一个提供区块链上人工智能基础设施的项目。opML 的挑战过程与 rollup 挑战非常相似，由以下三个关键组成部分构成：
ORA opML 上的验证游戏 | 来源：ORA 文件
通过这一欺诈证明机制，opML 利用区块链的安全性和可信度，同时为机器学习模型的训练和验证提供了一个具成本效益的环境。
6. 结论
Optimistic Rollup 正在投入大量精力改进欺诈证明和质疑协议，以继承更多以太坊的安全性，并创建一个更少信任的链。Arbitrum 预计将在今年年底通过 BoLD 达到阶段2，Optimism 也在朝着阶段2努力，依赖于争议游戏 V2 和多证明机制。到明年，Optimistic Rollup 的用户将能够以更高的安全性与网络互动，无需担心“Rollup 可能会拿走他们的资金”。此外，Vitalik 在他的博客中提到阶段1及以上的 Rollup 数量预计也会增加。
然而，每个协议仍有改进的空间，许多方面可通过 ZK 欺诈证明来增强。Kroma 已经在此基础上推进其协议，而其他协议如 Arbitrum、Optimism 和 Cartesi 也可以利用 ZK 欺诈证明保持更安全、更去中心化的方式。
在欺诈证明这一领域，不仅 Rollup 还包括其他协议正在投入大量研发资源。在“只需要一个诚实参与者”的前提下，欺诈证明与 ZK 相结合，可助力构建一个信任最小化的区块链架构，其影响终将成为我们切身可感的现实。
7. 参考资料
L2Beat
欺诈证明战争 | Luca Donnoh at L2Beat
Arbitrum 文件
Optimism 文件
Optimism 规格
无权限裁判的比赛 | Cartesi
Kroma 规格
BoLD：快速且低成本的争议解决
BoLD 的经济学
为什么乐观 Rollup 的挑战周期是 7 天？ | Kelvin Fichter at OP Labs
欺诈证明已崩溃 | Gabriel Coutinho de Paula at Cartesi
乐观时间旅行 | Yoav Weiss
关于 Kroma 主网首次成功质疑的介绍
解读基线去中心化的进展 | OP Labs
对基于欺诈证明的 Layer2 协议的不可归因的审查攻击
OP Labs 审计框架
无信任的推导 | Kroma
介绍 OP Succinct：在 OP Stack 上的完整有效性证明 | Succinct
Eigenlayer GitHub
Celestia 文件
Contribution DAO 博客
ORA 文件
声明：